2,000 Greater & Lesser Mysteries

home *** CD-ROM | disk | FTP | other *** search

/ 2,000 Greater & Lesser Mysteries / 2,000 Greater and Lesser Mysteries.iso / computer / virus / mys00505.txt < prev next >

Wrap

Text File | 1994-06-10 | 54.7 KB | 1,575 lines

Comparison: Products to Detect Changes to Programs Prepared by David J. Stang, Ph.D. and (c) 1990, 1991 by the National Computer Security Association Suite 309, 4401-A Connecticut Ave NW Washington DC 20008 Voice: 202-364-8252 BBS: 202-364-1304 This document may be freely distributed, but may not be altered in any way. This is a review of some of those checksum or CRC comparison programs. In it, I make an effort to concisely describe the merits of this class of products, and then to help you in selecting a product from their ranks. There is a difference between checksum algorithms and CRC -- cyclic redundancy check -- algorithms. The latter usually uses a table, and is usually a bit slower than the former. Despite the differences, many authors seem to use the words interchangeably, and we will continue the sloppy practice in this chapter. Each file has a unique fingerprint in the form of a checksum or CRC. Changes in any character within the file likely change the checksum or CRC. If a file's original CRC is known -- perhaps recorded in a file elsewhere -- and its current CRC is known, the two values can be compared. Any difference indicates that the file has been changed, and offers reason to investigate further. For example, DELOUSE allows you to build a list of critical system files that are normally subject to attack, and check them periodically for changes. If a program's size is changed, it must be concluded that some modification has occured to the file. If the size has not changed, some modification is still possible. A file that contains the simple message Hi Mom! could be modified so that it contained the message Hi Dad!, and it would not show any change in size. A much tougher test of whether a file has been modified is to compute the checksum or CRC cyclic redundancy check. At this writing, there are no viruses able to modify a file without modifying the file's CRC. Thus any checksum checker will work just fine in catching viruses, providing that you use it to establish checksums before a virus has modified your files. How is the checksum computed? Simply adding the values of all the characters in the file is not enough, as a file containing just "AE" would produce the same result as a file with just "EA". Rather, the first byte of a file is read, and an algorithm applied to it. This algorithm does something to the value of the byte, such as rotating the bits a certain number of times, and logically ANDING or ORING the bits to something else. The result of that algorithm is then applied to the next byte of the file. The process is repeated until the final byte is reached, and the remainder is recorded. During this process, different algorithms might be used for different portions of the code being processed. With most procedures, a small file produces a checksum value of the same size as a large file. Is there such as thing as "the" CRC value? No. The algorithm used defines the result. There are two popular algorithms in use: a standard CCITT CRC and a popular XMODEM CRC. Consider COMMAND.COM for DOS 3.3 dated 2/2/88 and taking 25308 bytes. Here are some of the checksums produced for this file by various programs. SSCRC and Validate (method 1) use the CCITT standard. All others in the list use some other approach. o BSearch, 16-bit CRC - 13369 (3439 h) o BSearch, CRCTT - 10994 (2AC0 h) o CHKSUM - 20011 (4E2B h) o CRCDOS - 59676 (E91C h) o Delouse, method 1 - 1073916 (1062FC h) o Delouse, method 2 - 1067428 (1049A4 h) o Delouse, method 3 - 1048666 (10005A h) o The Detective, CRC 1 - 26939 (693B h) o The Detective, CRC 2 - 54914 (D682 h) o Module Integrity Check - 24922 (615A) o SSCRC - 52167 (CBC7 h) o Validate, method 1 - 52167 (CBC7 h) o Validate, method 2 - 4024 (0FB8 h) o VCheck - 2141344 (0020ACA0 h) WHY DETECT CHANGES? There are several good reasons. o Viruses have great difficulty infecting your machine without making some change in it. To detect a change is to begin the process of detecting a virus. Although some are concerned that a change-detecting program cannot prove there isn't already a virus in your computer, the fact is that you needn't worry about this. If you infect your computer with a dozen viruses, then measure its state, one of these viruses will change that state in the next hour or so; a remeasurement establishes that something is afoot. o Occasionally things go wrong with computer hardware and software. You run CHKDSK and discover a number of lost clusters in a number of lost chains. You scrap these clusters, but wonder what files you've lost. A proper change-detection program will give you a list of files deleted since your last run. You can then restore them from your backups. o In many organizations, we only want to permit the use of "authorized software." Using a proper change-detection program, you can establish what software was added to the machine since your last run. Any "extra" software will quickly come to your attention. CAN A VIRUS BEAT THE SYSTEM? The answer may be yes. You need to know how, so it doesn't happen to you. The defeat can come at the hands of a CRC-aware virus (none exists yet) or at the hands of a stealth virus (there are several now). CRC-AWARE VIRUSES In theory, a virus could be written that would compute a file's CRC, add itself to the file, then replace additional characters from the file until the new CRC was the same as the old one. Such a virus would escape the attention of many checksum checkers. Programs could catch such a virus by using an incremental cyclic redundancy check approach. In this approach, files are dissected into randomly-sized blocks of data, using dynamic block size allocations that allow files as small as one byte to be accurately checked. CHECKUP uses this approach. It scans and compares every byte of the target files on a block-by-block basis. If the recorded file sizes, any of the block CRC comparisons, or the CRC totals do not match, CHECKUP alerts users that the target files have been altered. Another approach to the problem is to compute the check in two different ways. For example, if both a checksum and a file size were to be calculated and recorded for later comparison, it is unlikely that a virus could be modified without mismatching on one of the comparisons. Or if checksums were to be calculated using two different algorithms, the virus would again likely fail to fool both techniques. Thus if some future virus were to compute checksums prior to infections, pad their viral code with characters that maintain checksum integrity and then infect, CHECKUP could catch it. STEALTH VIRUSES A stealth virus is able to defeat a checksum program if it loads into memory before the checksum program runs. The stealth virus can then detect the checksum program as it attempts to read each program on the disk, and before letting the checksum program see the file it is trying to read, extracting the virus from it. After the checksum program is satisfied that there is no virus in the file, the virus in memory can re-insert it into the file just checked. Such a problem can be easily avoided: simply boot the system from an uninfected floppy, then run your checksum program from it. In the tables presented here, space has been provided for you to rate an additional product. PRODUCT COMPARISONS EASE OF USE Conducting these evaluations was not easy. In the table below, I record my joy or frustration in trying to master the program. Alert This program makes claims of ease of use, with a pop-up, drop-down menus, mouse support, nifty sound effects, and the like. But the blinking text on the screen will certainly drive you crazy, if you are still sane after waiting, Alert would like to run McAfee's scan every time you add a file to the list it will check; it doesn't accept wild cards, so if you thought you would do a checksum on all of your files, assume that you won't be able to install it in less than a week. Installation and simple evaluation took 53 minutes. The Antibody Test Antibody's installation is extremely easy, if it works. You cannot simply copy the files to your hard disk -- you must let Antibody do it for you. In the process, Antibody wants to check the integrity of your distribution disk. If you have any alien file on this disk, Antibody will abort after 3 or 4 minutes of self-examination. Beat the system by clearing the read-only and hidden attributes of SIGNATURE.DAT, then rename it. Antibody will create a new file for you and proceed. The manual includes a comprehensive list of error messages and their meanings. BSearch No installation required! Copy BSEARCH.EXE to anywhere on your hard disk, and run it with the obvious wildcards. For example, BSEARCH C:\*.* will examine everything. CHKSUM Simply copy to anywhere on your hard disk and enter "CHKSUM". You'll be prompted for what you should have entered. Checkup The most difficult of all the packages reviewed here. Documentation spans five files, and numbers almost 100 pages. With such a mass of instructions, you are unlikely to have any success in installing the program. The verbosity extends to the log file, which you can create to record any file mismatches. The log file for a single run on 183 files was 270K - nearly 2K per file. Should you try to use the product on a large hard disk, your log would be worthless. CRCDOS As with CHKSUM, simply copy to anywhere and go! Instructions will appear on the screen if you simply enter "CRCDOS." Delouse It took just four minutes to completely understand how Delouse works and to begin building the file of CRC values. Installation is nothing more than copying a few files to anywhere on your hard disk. Delouse can also be run from a floppy. The Detective Copy and go. When first run, the program pops up a simple menu that works very well. You'll be asked what drives to process and what file extensions to check. Entering * will process everything. You'll be asked if you also wish to scan for viruses (meaning to compute CRCs) as you produce the file list for subsequent checks. Also, The Detective keeps itself up-to-date with each run. On every run, the most recent signatures are copied to the "old" list, and new signatures are computed for comparison. F-Prot Copy F-OSCHK to any location on your hard disk and enter F-OSCHK. It will display five numbers which are encrypted checksums of the partition table, boot record, and three operating system files. AUTOEXEC.BAT can then be given a line beginning with (path) F-OSCHK and followed by these five values. FICHECK Seemingly easy to use. Can be run from a menu or as a command line in a batch file. However documentation for the command line operation is poor, and misleading. Module Integrity Check Copy the file MIC to anywhere on your hard disk and enter MIC. There are no menus, nothing to select. You'll create a list of CRCs, if none exists, in your root. If one exists, it will be renamed "OLD", and another will be created. The two will be automatically compared. You'll be notified of any changes, any added files, and any deleted files. You'll also be notified if nothing has changed. All information is automatically sent to reports in the root. Nothing could be simpler. Novirus Copy the program to anywhere on your hard disk, and it makes a hidden file in the root containing what it claims is encrypted CRC, file date, time, and size information for each of the three system files. Installation and use are very easy. SSCRC Very easy. Copy the file to your hard disk, and run the program. Onscreen instructions tell you to enter /F to create the File of CRCs or /C to Check files against these CRCs. Requires ANSI.SYS Validate Very easy to use for finding the CRC of a single file. Simply copy VALIDATE to your drive, and run it. Impossible to use for checking the CRCs of all files, as it does not work with a list, does not accept wildcards, and will not compare current CRC with stored CRC. VCheck Fairly straightforward. You may need to follow the example in the manual to guess the spacing required for parameters in the command line. Results are displayed on your screen, and you'll need to press a key to continue scanning, after the screen fills. This ensures you'll spot a surprise change in a file, but doesn't deliver the kind of power that suits it for a batch file. Not menu-driven. VirusGuard Simply type INSTALL. VirusGuard will install itself on your hard disk and scan all COM and EXE files for their signatures. It will also modify your AUTOEXEC.BAT to automatically invoke RAMWATCH on subsequent boots. Our copy of the program did not come with documentation, however, so we are a bit limited in our review here. NUMBER OF TECHNIQUES The program should compute checksums using two different approaches, or compute both file size and checksum, to ensure that a virus doesn't modify a file in such a way that the checksum isn't changed. Gilmore Systems has a program called PROVECRC that creates a modified version of a file that is different, but that has the same CRC as the original. The program proves that a single CRC is not fool-proof for virus detection, for it is possible to write a virus -- much like they wrote PROVECRC -- which can add code to your programs without changing the CRC. When two algorithms are used, PROVECRC creates changes undetected by one, but detected by the other. Alert Alert uses different algorithms on different portions of each file. A file records the results of these algorithms in encrypted form in a file which covers all of a group of files you wish to check. It is very unlikely that any virus author would have the interest or patience to break the scheme. The Antibody Test Antibody lists all files added or deleted since the last comparison, as well as showing any changes in size, date, time, or attributes. BSearch Stores filenames (with paths), file sizes, 16-bit and 32-bit checksums in an indexed databases. Uses a binary tree indexed database structure to store the files quickly and allow even quicker searches and updates. CHKSUM Uses a single 16-bit checksum approach. Checkup Offers three different options for calculation: table-driven incremental CRC, cumulative CRC, and cumulative checksum. CRCDOS Uses a single 16-bit checksum approach. Delouse Uses three different checksum algorithms. All are simple, but slightly different in the way they calculate the checksum. One of these algorithms is chosen at random when Delouse starts, and the method number is recorded in a data file. You can force Delouse to choose one of the three methods if you wish. The Detective Uses two different 16-bit CRC algorithms. F-Prot F-OSCHK uses just one algorithm. FICHECK FICHECK uses one 16-bit algorithm, MFICHECK uses another. Both are bundled in the same package. Module Integrity Check Uses one 16-bit algorithm. Novirus Appears from testing that Novirus uses no checksum or CRC algorithm, despite the claims of its documentation. Using a sector editor, for instance, the word "Microsoft" was changed to "Machosoft" in COMMAND.COM. Novirus was unable to recognize this. I changed the attributes of the hidden system files, and again Novirus failed to detect the change. I renamed COMMAND.COM, infected it with Jerusalem, and renamed it to COMMAND.COM. Novirus recognized the change, but only because of the increased file size. When I used NU to reduce the size of the infected file to its original size, as listed in the root directory, Novirus did not recognize it as a problem. It appears that no checksumming is done, although this is claimed in the documentation. Checks on file existence, date, size, and time do appear to be done. For instance, I booted, deleted COMMAND.COM, and ran Novirus. Novirus halted the system. It also halted the system when I used NU to increase the size of COMMAND.COM to 999999999. SSCRC Uses one 16-bit CCITT CRC algorithm. Validate Uses two 16-bit algorithms, one of which is CCITT CRC. VCheck Uses one 32-bit algorithm. VirusGuard Appears to use one algorithm. CRCs are encrypted. SCANNING OF CRITICAL SYSTEM FILES On an MS-DOS hard disk, there are five critical system files that are read during the boot process: the partition table, the boot record, two hidden system files, and COMMAND.COM. Because many viruses take up residence in the partition table, boot record, or COMMAND.COM, it may be desirable to check these files on each boot. Not all CRC programs, however, can check all of these files. Two points are awarded for each file it can check. Note that viruses rarely touch the two hidden system files, and many do not touch COMMAND.COM Quite a few, however, get into the partition table of the hard disk or boot record of floppies. Alert Alert cannot examine the partition table or boot record. It can check the other three files. The Antibody Test Antibody does not check the partition table. It does check the other four files automatically, however. BSearch Does not scan partition table or boot record. CHKSUM Does not scan partition table or boot record. Checkup Does not scan partition table or boot record. CRCDOS Does not scan partition table or boot record. Delouse Does not scan partition table or boot record. The Detective Does not scan partition table or boot record. Further, the evaluation version (reviewed here) will not examine anything in the root, which is certainly the two hidden system files and likely COMMAND.COM. F-Prot F-OSCHK scans all five files. FICHECK Automatically checks the CRC of the partition table and the boot record, and logs this along with available disk space and FAT ID byte. For all files checked, logs date, time, size, attributes, and CRC, and reports any discrepancies. Checking of hidden system files, COMMAND.COM, etc. is at user discretion. Module Integrity Check Does not scan partition table or boot record. Novirus Does not scan partition table or boot record. SSCRC Does not scan partition table or boot record. Validate Does not scan partition table or boot record. VCheck Does not scan partition table or boot record. VirusGuard Does not scan partition table or boot record. COMPLEXITY OF CHECKING ALGORITHM A 32-bit CRC is potentially harder for a virus to beat than a 32-bit CRC; a pair of calculations is harder than a single calculation. In this table, 10 points are awarded for the use of a 32-bit CRC or two 16-bit CRCs; 5 points for a single 16-bit CRC; 0 for no CRC. Alert Algorithm is not discussed in the documentation. However, the encrypted CRC for just one file is 748 bytes - about 5% of the checked file's length. This suggests that the algorithm is essentially unbreakable. The Antibody Test Algorithm is not discussed in the documentation. However, the encrypted CRC for just each file is 128 bytes. This suggests that the algorithm is essentially unbreakable. BSearch Performs both 16-bit and 32-bit checksums. CHKSUM Performs CRC-16 -- 16 bit cyclic redundancy check. Checkup Performs CRC-16 -- 16 bit cyclic redundancy check. Results are encrypted. CRCDOS Performs CRC-16 -- 16 bit cyclic redundancy check. Delouse Performs CRC-16 -- 16 bit cyclic redundancy check. The Detective Performs both 16-bit and 32-bit cyclic redundancy checks. F-Prot Not described in documentation. Encrypts recorded checksums. Uses only one algorithm. FICHECK Computes CRC with FICHECK, modified CRC with MFICHECK. You can run both, if you wish, to defeat any imaginary virus that is able to defeat one of these approaches. Module Integrity Check Computes a checksum on part of the file. Uses only one algorithm. Novirus Does not appear to do any CRC/checksum computation. SSCRC Uses only one algorithm -- a 16-bit CCITT standard CRC. Validate Uses two 16-bit algorithms, one of which is CCITT CRC. VCheck Uses one 32-bit algorithm. VirusGuard Unknown. SPEED WHEN CHECKING ALL FILES From time to time, it may be desirable to check all files on the hard disk for changes. However, if this process takes a long time, users will not do it as often as they should. What is the speed of checking files? For our tests, we did CRC calculations on a 20Mb hard disk in a 12Mhz XT. The XT had a Norton SI of 1.8 for its computing index, and 1.4 for its disk index, an overall performance index of 1.6 that of an IBM XT. It had a total of 2.3 Mb in 134 files in 19 directories. In each case, the checksum program was run from a floppy. Timing was done with a shareware program called TIMER. Numbers reported here are per file. Since it is not the number of files, but the number of bytes, that determines the overall speed of operation, your times will vary if your files are larger or smaller, on average, than those in the test suite. Our average file was 18,651 bytes. So to say that scanning files took about 2 seconds a piece is to say that the program could scan 9,325 bytes per second. A 20 Mb hard disk, full to the brim, would take such a program 37 minutes to scan fully. If you restricted the program to COM, EXE, OVL, BIN, SYS, and other executable files (an intelligent restriction), you might cut this time in half or more. Alert I could not imagine waiting while Alert checked all files on the hard disk. Scanning just one file took 13.5 seconds. Checking the 2.3 Mb on the test hard disk would have taken about 17.5 minutes. This is unacceptable. The Antibody Test Antibody is slow, but not as slow as some of the others tested here. It took 6 minutes, 14 seconds to scan all programs on the hard disk -- 71 files, about 5 seconds a piece. BSearch Building the initial database of all files -- including manuals and other files -- took BSearch 10 minutes, 35 seconds -- about 4.7 seconds each. Then scanning against this file took 10 minutes, 20 seconds -- about 4.6 seconds each. CHKSUM To compare the three DOS files with CRCs previously computed took 5.6 seconds, about 1.9 seconds each. Testing everything in the root took 13 seconds for 8 files, about 1.6 seconds each. Checkup To build a list of CRCs for 183 files took 9 minutes, 16 seconds, about 3 seconds each. It took 8 minutes, 35 seconds to use the author's proprietary "enhanced" CRCs, about 2.8 seconds each. Using the checksum approach took about 2.8 seconds each. CRCDOS To build a list of CRCs for 146 files, CRCDOS took 6 minutes 27 seconds, about 2.6 seconds each. Testing everything on this list took 6 minutes, 24 seconds, again about 2.6 seconds each. Delouse To build a list of CRCs for 146 files, Delouse took 2 minutes 38 seconds, about 1.1 seconds each. Testing everything on this list took 2 minutes, 35 seconds, again about 1.1 seconds each. The Detective To build a list of CRCs for 146 files, The Detective took 3 minutes 57 seconds, about 1.6 seconds each. Testing everything on this list took exactly the same length of time. F-Prot Scans five system files in 10.0 seconds, 2 seconds per file. However, F-OSCHK cannot be made to calculate checksums on any files but these. FICHECK To build a list of CRCs for 146 files, FICHECK took 5 minutes 27 seconds, about 2.2 seconds each. Testing everything on this list took 5 minutes, 24 seconds, again about 2.2 seconds each. Module Integrity Check To build a list of CRCs for 146 files, MIC took only 1 minute 30 seconds, about .6 seconds each! Testing everything on this list took the same length of time. The program achieves this blazing speed by performing a checksum only on the parts of the file that a virus is likely to infect: the top and the bottom. Novirus Scans three system files in 1.54 seconds, .5 seconds per file. However, cannot be made to check any files but these, and does not appear to calculate checksums. SSCRC To build a list of CRCs for 146 files, SSCRC took 6 minutes 27 seconds, about 2.6 seconds each. Testing everything on this list took 6 minutes, 10 seconds, about 2.5 seconds each. Validate To validate a selected file requires issuing the validate command for that file, then looking the result up on-line, from a BBS in California. Minimum time required: perhaps 3 minutes per file. VCheck To build a list of CRCs for 87 COM and EXE files, VCheck took 1 minute 55 seconds, about 1.3 seconds each. Testing everything on this list took 1 minutes, 25 seconds, about 1 second each. VirusGuard To build a list of CRCs for 87 COM and EXE files, VirusGuard took 1 minute 39 seconds, about 1.2 seconds each. Testing everything on this list took 1 minute, 42 seconds, again about 1.2 seconds each. EFFICIENCY IN CHECKING ALL FILES Does the program permit checking of all files with some option such as "/ALL", or is it necessary to feed the program a list of all the files you wish checked? The latter approach can be grueling for any user with a large hard disk! Is there an upper limit to the number of files that can be checked? Is the program smart enough to check other logical drives, such as D:? Alert No. There does not seem to be any such efficiency possible. The programwants to scan one file at a time, and add one at a time to its list. Alert can only manage a list of about 200 files. Alert does not know that viruses do not inhabit documentation, and is likely to begin by scanning its own manual! Creating a list to be checked is very labor-intensive. The Antibody Test Antibody automatically scans the entire hard disk upon installation. It can manage about 3900 file signatures. Antibody ignores drives D:, E:, etc., however. BSearch There is no upper limit to the number of files that can be checked. Ignores D:, E:. As with Antibody, BSearch can be called from a batch file that scans specified drives, directories. Output showing changes can be routed to the printer, if this is desired. CHKSUM Power is about equivalent to BSearch. You can do almost anything with batch files, but you will need to be a bit handy with an ASCII editor to do so. You'll need to specify if you want CHKSUM to look at D: for you. There is no limit on the number of files that can be checked. Unlike BSearch, CHKSUM will not look at subdirectories of the specified target, unless you tell it to. Checkup Checkup simply processes everything on your hard disk, and does not work from any input list. There is no upper limit on the number of files that can be scanned, other than your patience. Checkup is happy to point out that files have been changed, when they haven't been. This occurs because Checkup creates one X.XUP for every file beginning with X. Thus the signature for X.BAT is stored in X.XUPand the signatures for X.COM, X.SYS, X.BAK, etc. are compared with the contents of this file. With perhaps 10% of such "claims" wrong, you will lose patience with it quickly. Checkup gets a 10 for efficiency, a 0 for accuracy. CRCDOS CRCDOS will process an ASCII list of files you give it, a list you can create by entering CHKDSK *.* /v >> filelist You can then feed CRCDOS this list with a command such as CRCDOS -m crclist filelist. There is no upper limit on the number of files that can be scanned. D: and other drives are ignored unless CRCDOS is told to work them over. Like CHKSUM, CRCDOS will not automatically look at subdirectories of the specified target, unless you tell it to. Delouse Much like CRCDOS. Delouse will process an ASCII list of files you give it, a list you can create by entering CHKDSK *.* /v >> delouse.dat You can then feed Delouse this list with a command such as DELOUSE MAKE. This creates a file DELOUSE.CHK file, used during checking. To check, you enter DELOUSE CHECK. There is no upper limit on the number of files that can be scanned. D: and other drives are ignored unless Delouse is told to work them over. Like CHKSUM and CRCDOS, Delouse will not automatically look at subdirectories of the specified target, unless you tell it to. The Detective Intelligent menu-driven design. Prompts for drives, file extensions. It is easier (and more sensible) to make it simply check everything than to be selective. F-Prot Very efficient, but scans only the five system files. FICHECK Intelligent menu-driven design. Prompts for drives, file extensions. It is easier (and more sensible) to make it simply check everything than to be selective. Some selectivity (with *.COM, *.EXE, etc.) is easy; other selectivity (specific files) is harder to do. Module Integrity Check Checks all files automatically. Processes only the current logical drive. Cannot be made to scan selectively. Creates all reports, as disk files, automatically. Because it is so fast, we award nearly full points here. Novirus Cannot be made to check multiple drives. Cannot be made to check files other than the three system files. SSCRC There is no upper limit to the number of files that can be checked. Ignores D:, E:. As with Antibody and BSearch, can be called from a batch file that scans specified drives, directories. Output showing changes can be routed to the printer, if this is desired. Validate No. There does not seem to be any efficiency possible. The programwants to scan one file at a time, and is unable to compare its results with anything in a list of recorded checksums. VCheck Checks all COM and EXE files automatically. Processes whatever logical drive you specify on the command line. Cannot be made to scan selectively. Cannot be made to scan SYS, BIN, OVL, or other files that might become infected. Creates all reports, as disk files, automatically. VirusGuard Checks all COM and EXE files automatically. Processes whatever logical drive you specify on the command line. Cannot be made to scan selectively. Cannot be made to scan SYS, BIN, OVL, or other files that might become infected. If a file is changed, the machine pauses during signature checking, with the message "X.X has been modified. Press F1 to acknowledge." USER CONTROL OF FILES TO BE CHECKED Because checking all files can take some time, users may wish to provide the program with a list of files to be checked. Can this be done? Can the user use their text editor or other convenient tool to build the file list? Alert Yes. Users select those files they wish to check, via menu. The menu system can be used to build a file list for subsequent use. The file list is encrypted and not editable with any program other than Alert, however. The Antibody Test No. Antibody cannot be given a short list. You may add to its understanding of what should be checked, but cannot subtract. BSearch You can only list by file type and directory. Thus you can specify all COM files within each of 4 directories, all EXEs within another 2 directories, etc. Each instruction is offered on a separate command line, and can be run from a batch file. The database cannot be edited with most word processing programs, however. CHKSUM Building the list of files to check can be done easily by redirecting the program's output (">>") to a file, then editing this file into a batch file. Checkup No control. CRCDOS Extremely easy to use here. Hand CRCDOS a list of files, and it builds a list of CRCs for those files. Hand it this list, and it compares current and stored CRCs for changes. Delouse A bit easier than CRCDOS, even, in that file names to scan and to compare are hard-coded, so the command line is simpler: you only need to enter "Delouse Make" or "Delouse Check" The Detective The user controls the drive(s) to check, and the file extensions to check, but cannot control the directories to check or provide a list of specific files. F-Prot The user can choose to not check any of the five system files. But the user cannot get F-OSCHK to scan any other files than these. FICHECK The user controls the drive(s) to check, and the file extensions to check, but cannot control the directories to check or provide a list of specific files. Module Integrity Check MIC is so fast that it doesn't make any sense to attempt to force it to scan selectively. Let it scan everything. You're done. MIC is certainly the easiest to use, most efficient of all the programs described in this chapter. Novirus Offers no control over the checking process. Takes only one command line - /I makes it start over with a new database of information on the three files. SSCRC Offers no control over the checking process other than permitting scan of a directory, rather than the entire drive. Validate You can make it scan any file in any directory. But scanning two files requires two commands. Not practical for real-life. VCheck Offers no control over the checking process other than permitting scan of a directory, rather than the entire drive. VirusGuard VirusGuard is so fast that it doesn't make any sense to attempt to force it to scan selectively. Let it scan everything. You're done. MIC is certainly the easiest to use, most efficient of all the programs described in this chapter. ADDING SELF-CHECKING TO FILES The most efficient approach to checking files is not to check only critical files, or all files, but rather to check files as they are run. This checking can be done with either code which is added to each file, or with a memory-resident driver, that monitors file access. Adding code to a file is the idea of "vaccination." The file is modified so that when it is run, control is first passed to the appended code, which then calculates the checksum of the file with the checksum that was stored in that file at the time of vaccination. A failed comparison can result in an alert to the user. There are a few drawbacks to the approach. It slows processing a small amount, it enlarges each file a small amount, it may not work on COM files that are nearly 64K in size, since 64K is the largest size supported by the COM format; it cannot work with BIN, SYS, and OVL files; it cannot work with archived, self-extracting EXE files, and so on. While some authorities, such as Rich Levin, view such approaches as substantially flawed, we are unconvinced. Alert This feature is not offered. The Antibody Test This feature is not offered. BSearch This feature is not offered. CHKSUM This feature is not offered. Checkup This feature is not offered. CRCDOS This feature is not offered. Delouse This feature is not offered. The Detective This feature is not offered. F-Prot The F-Prot package includes F-XLOCK, a program that can make any other COM or EXE self-checking. Entering F-XLOCK *.* will protect all COM and EXE files in the current directory. When infected, the program will hang the system and report "THIS PROGRAM HAS BEEN INFECTED!" and the system hangs. FICHECK This feature is not offered. Module Integrity Check This feature is not offered. Novirus This feature is not offered. SSCRC This feature is not offered. Validate This feature is not offered. VCheck This feature is not offered. VirusGuard This feature is not offered. OPTIONAL SYSTEM LOCKUP ON DETECTION OF MODIFICATION Many things can modify a program: a virus, a hacker, an error in using a sector editor. If a program has been modified, do you want to try to run it? The smart money says no, let's stop right now and see what has happened here. Running any program that contains a virus is certain to spread the virus. It might be desirable if the system is able to prevent any modified program from running. Alert You are given ample warning about what files have been modified. The warning is both auditory and visual, and the screen requires you to press a key after reading what has happened. The warning may not be accurate, however. I swapped the names of two test files, and Alert was unable to find one, told me the other was the wrong size. Both, in fact, were where they had been, but were completely modified. Further, the warning on the screen tells the user to consult the manual, rather than telling the user what to do next. The Antibody Test The log shows what has changed, and how. Optionally, you may ask the program to display any text in any file which has been changed since the last check. However, there is no system lockup if a modification is detected, nor are there any audible warnings. BSearch The log shows what has changed, and how. There is no system lockup if a modification is detected. A faint beep can be heard when any change is detected. CHKSUM Upon detecting a changed file, CHKSUM beeps and displays a message. But it doesn't pause in its labors, and the result of a massive infection is likely to go scrolling off the screen. No lockup takes place on mismatches. Checkup The documentation indicates that the system can be set to lockup upon detection of a mismatch. We were not able to create this effect on our test machine, however. Further, although the documentation claims to permit production of a log file, we were not able to do this. Our copy was downloaded from the author's BBS. CRCDOS There is an extensive screen message whenever a change is detected, but the system does not beep. No lockup takes place on mismatches, either. Delouse There is a modest screen message whenever a change is detected, but the system does not beep. No lockup takes place on mismatches, either. The Detective You won't get a beep or message on the screen. A report, sent to disk or your printer, lists the files that have been added, deleted, or changed since the last run of The Detective. Far too subtle for most users. F-Prot If any of the programs in the F-Prot package becomes infected with any virus, or changed in any way, it reports "THIS PROGRAM HAS BEEN INFECTED!". If any program is protected with F-XLOCK, it will then hang the system. FICHECK You won't get a beep or message on the screen. A report, sent to disk or your printer, lists the files that have been added, deleted, or changed since the last run of FICHECK. Changes noted can include size, date, time, crc. If the report is not requested, or not requested correctly, or sent to disk, users may not become aware of virus-induced changes. Module Integrity Check You get several very nice reports, automatically placed in your root, showing files removed, added, and changed since the last run. If a file has been changed for any reason, MIC will tell you, and will tell you to read the change report. Novirus If Novirus does manage to find a problem with a change in the time, date, size or presence of one of your three system files, it will halt the system and display a full-screen warning message. SSCRC You won't hear a beep. You might see a notice go past on the screen when a changed file is found. At the end of the scan, you'll see a summary table, including a row showing number of files failing CRC. Their names are listed at the top of REPORT.CRC, placed in the root. Your batch file that invokes SSCRC could send this report to the printer, if you wished. There is no system lockup. We might want this less subtle. Validate Because Validate makes no comparison with pre-recorded CRCs, it cannot know if there is a problem with a file. It is happy to scan infected files and report their CRCs. VCheck You won't hear a beep. You will see a list, on screen, of exactly which COM and EXE files have different CRCs or sizes. Their names can be listed in a report you create, which can be sent to the printer. There is no system lockup. VirusGuard No beeps. But you'll see the changed program listed on the screen, with the message that it has been modified. You'll need to tap a key to remove the message from the screen. There is no system lockup, and no hard copy report or file of changes is created. SELF-PROTECTION OF CHECKSUM PROGRAM If a checksum program becomes infected, it then puts the virus into memory before it begins to run. A stealth virus in memory is able to remove itself from any file as the file is checksummed, preventing the checker from finding the virus. Thus we need some notification that the checksum program has been infected. Ideally, the checker reports that it has been infected and quits running. To test this, we infected each checker with Jerusalem-B, and tried running it. Alert Alert runs no worse with an infection than without one, and never seems to notice that it has become a carrier of Jerusalem. The Antibody Test As with Alert, Antibody runs just fine after infection. BSearch As with Alert and Antibody, BSearch runs just fine with a Jerusalem infection. CHKSUM Runs well when infected. Checkup Runs as well when infected as when not infected -- poorly. CRCDOS Runs well when infected. Delouse Runs well when infected. The Detective Runs well when infected. F-Prot F-OSCHK reports that it has been infected. F-XLOCK reports that it has been infected, and hangs the system. FICHECK Runs well when infected. Includes an option to self-check for virus infection. The self-check works. After a few moments, it will report "Error - This program has been altered or tampered with!" However, the user must invoke this option deliberately and manually. Module Integrity Check Runs well when infected. Novirus Runs well when infected. SSCRC Runs well when infected. Validate Runs well when infected. VCheck Runs well when infected. VirusGuard Runs well when infected. VENDOR INFORMATION o Alert. Version 2.20, available from the NCSA BBS as ALERT220.ZIP. Also available from Robert W. Reed, 3858 Waterview Loop, Winter Park, FL 32792. Price: $25 each for 1-10 licensees. o The Antibody Test, version 1.03B. Available from the NCSA BBS as ANTIBODY.ZIP. Also available at no charge from Commander, TRADOC, ATTN: ATIS-S (Major Richard W. Adams), Ft. Monroe, VA 23651-5000. o BSearch. "If you find BSearch of value, a contribution of $10 would be helpful." Available from the NCSA BBS as BSEARCH.ZIP, or from David Harris, POB 2058, El Paso, TX 79951. o CHKSUM is available from the NCSA BBS in a file called CHKSUM.ZIP. It is also available from its author, Bob Taylor, 8602 Woodlake Drive, Richmond, VA 23229. The author does not request a contribution. The package includes C source code. o Checkup v. 3.9 (Levin) "This is not free software. You are granted a limited license to evaluate this program for ten days in your home or office. If you continue to use this program, you must register with the author. Registration fees are $24.95 per copy for home users and $49.95 per copy for office users." Available from the NCSA BBS as CHKUP39.ZIP or from Richard B. Levin, POB 14546, Philadelphia, PA 19115. o CRCDOS version 1.0. Available from the NCSA BBS as CRCDOS.ZIP. This ZIP file includes C source code. Written by R.E. Faith, January 11, 1988. Released to the public domain, on condition that no fee be charged for distribution, that authorship information concerning source and any modifications will be retained, and that the code is not included as part of a commercial package. o Delouse version 0.9 Available from the NCSA BBS as DELOUSE.ZIP. Written by Phillip M. Nickell, February 28, 1988. Includes Pascal source code. No fee is requested. No copyright is taken. Appears to be public domain. Thanks, Mr. Nickell! o The Detective version 1.2 Available from the NCSA BBS as DETECT.ZIP. "The free version of The Detective is expressly prohibited for use in commercial, educational, and governmental institutions except for the purpose of evaluation." The price per computer, if you choose to register, is $25 for 1-50 computers, and less with more. You may order the current version from PC Solutions, POB 742, Mequon, WI 53092. (414) 241-9119. The shareware version, distributed via bulletin boards, is unable to process files in the root directory. o F-Prot, version 1.12, is available from the NCSA's BBS as FPROT112.ZIP. Version 1.12 of this package contains a large number of extremely useful anti-virus tools. From the standpoint of the present review, only two are relevant, however: F-XLOCK (which permits all programs to check for CRC changes as they are executed) and F-OSCHK (which checks the partition table, boot record, two hidden system files, and COMMAND.COM) F-Prot is available from Fridrik Skulason, Box 7180, IS-127 Reykjavik, Iceland. Pricing: Skulason suggests $15 for 1-7 computers, and lower payments on larger volumes. o FICHECK, version 5.0, comes bundled with MFICHECK 5.0 and PROVECRC ver 1.0. It may be downloaded from the NCSA BBS as FICHECK5.ZIP. It is available from the author, Chuck Gilmore, Gilmore Systems, POB 3831, Beverly Hills, CA 90212-0831. Pricing: "A 30 day trial period is granted. Afterward, you may either order one of the commercial versions or destroy the evaluation copies." Two commerical versions are available: XFICHECK (eXtended FICHECK) for $15 and PFICHECK (Professional FICHECK) for $20. o Module Integrity Check, version 1.0, is available from the NCSA BBS in a file called MIC10.ZIP. Pricing: "This program may be used by anyone free of charge... Anyone who finds this program of value is encouraged to make a voluntary donation to the author... Even if you do not make a donation you are still free to use this program as you see fit." Author: Steve Leonard, 260 Dunbar Road, Hilton, NY 14468. o Novirus version 3.0, accompanied by documentation for version 2.0, is available in a file called NOVIRUS3.ZIP on the NCSA BBS. It is also available from the Interconnect BBS, 703-827-5762. Author: Jeffrey Morley. Price: free. o SSCRC, version 1.4, is available in a file called SSCRC.ZIP from the NCSA BBS. Pricing: "If you use this utility to protect your system, do the right thing and send us $10", says the author. It is available from OSR, 561 Blaxland Road, Eastwood, 2122, NSW, Australia. o Validate, version 0.3, is available in a file called VALIDAT3.ZIP from the NCSA BBS. It is also available at no charge from Computer Virus Industry Association, 4423 Cheeney St., Santa Clara, CA 95054. (408)-727-4559. Price: free. o VCheck, version 1.1E, is available in a file called VCHECK.ZIP on the NCSA BBS. Pricing: "If you use VCHECK, send a registration of $25 to Systemberatung Axel Dunkel, Robert-Schuman-Ring 37, D 6239 Kriftel, West Germany." o VirusGuard. SOME OBSERVATIONS Once again, the correlation between price and value is upset. Many of our highest scoring packages were the cheapest. We note also the contradiction betwen our ratings and those published elsewhere. The documentation accompanying Checkout notes that the product is Compute!'s PC Magazine Editors choice for virus protection, is the featured virus detection system in Dvorak and Anis' "Dvorak's Guide to PC Telecommunications", etc. We found it at the bottom of our scoring system. You may wish to review our ratings of this product. OTHER EVALUATION CONSIDERATIONS We did not compare products on the following items, but you may wish to: o Can the program work on files with hidden, system, read-only attributes. o Can the program work from floppy disk? This is valuable if you wish to use the program to monitor another user's machine, for instance, to see if they are clandestinely running a golf game that is not on the approved corporate software list. It is also valuable for guarding against stealth viruses. o Can the program produces separate lists of deleted files, added files, and changed files? Separate lists may have benefits over a massive list of changes. o Do you have control over whether the program updates its baseline database? If the program updates this everytime it is run, you will lose your history file. +++++